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Abstract 

Increased navigation speed is desirable for lunar 
rovers, whether autonomous, crewed or remotely oper- 
ated, but is hampered by the low gravity, high contrast 
lighting and rough terrain. We describe lidar based nav- 
igation system deployed on NASA’s K10 autonomous 
rover and to increase the terrain hazard situational aware- 
ness of the Lunar Electric Rover crew. 

1 Introduction 

High speed mobility (by planetary rover standards) 
is desirable for more efficient exploration of the lunar 
surface, particularly if human crews are present there. 
NASA’s Lunar Electric Rover (LER, Figure 1) can drive at 
lOkm/h (3m/s) on rough terrain, faster on known smooth 
surfaces. By comparison, the MER vehicles moves at a 
few cm/s while stopping regularly. 

Driving on the Moon is complicated by the low grav- 
ity, rough terrain, high contrast lighting and alien envi- 
ronment. Under the ^ g lunar gravity a vehicle becomes 
airborne at relatively modest speeds (driving the Apollo 
era lunar rover at 7 mph was reportedly like being aboard 
a rowing boat for this reason). The reduced gravity also 
lessens vehicle-ground friction. Together these effects in- 
crease maneuvering distances. 

Astronauts complained of difficulty discerning sur- 
face features on the Moon under certain lighting condi- 
tions, such as with the sun behind them. The lack of ter- 
restrial depth cues compounds the difficulties of driving. 

The 3 sec signal round trip time delay to the Moon 
permits tele-operating a vehicle from Earth (e.g. Lu- 
nakhod) with difficulty (increasing with speed). 

This paper describes our robotic rover navigation sys- 
tems, currently running on NASA’s autonomous or tele- 
operated K10 rover (Figure 2) and as a crew aid on the 
LER for increasing pilot situational awareness of the sur- 
rounding terrain. We address terrain sensing for 4 differ- 
ent classes of rovers: K10, the Lunar All Terrain Utility 
Vehicle (LATUV, Figure 3), the LER and the LER oper- 
ating under lunar gravity and time-delayed tele-operation. 
Subsequent sections describe the terrain mapping and haz- 



Figure 1. : NASA’s Lunar Electric Vehicle (LER), de- 
signed to sustain a 2 person crew and drive at 3m/s on 
rough terrain 



Figure 2. : NASA’s K10 rover, an autonomous or tele- 
operated robot designed for robotic site survey [3] at 
speeds up to 0.6 m/s 




Figure 3. : The Lunar All Terrain Utlity Vehicle 

(LATUV), developed by Protoinnovations LLC under a 
NASA SBIR as a research platform for lunar navigation 
and capable of speeds up to 2m/s. 


ard detection software, pose estimation, the rover software 
infrastructure for command and data handling, the graph- 
ical user interface and performance figures. 

2 Problem Statement 

Table 1. : Rover specifications. LER Moon refers to the 
LER operating under lunar gravity and time delays. 



K10 

LATU\ 

r LER 

LER 

Moon 

Speed (m/s) 

0.6 

2.0 

3.0 

2.0 

Max pitch rate 

10 

10 

10 

10 

(°/s) 

Max deceleration 

2.0 

2.0 

2.0 

1.0 

(m/s 2 ) 

Reaction time (s) 

2.0 

2.0 

2.0 

5.0 

Min obstacle size 

10 

15 

15 

15 

(cm) 

Min hole size 

30 

45 

50 

50 

(cm) 

Max slope (°) 

30 

30 

35 

35 


We address the problems of terrain mapping and haz- 
ard detection for navigating a set of lunar rover prototypes 
under on lunar like terrain at relatively high speeds, sum- 
marized in Table 1. The maximum pitch rates are for 
travel on level (but bumpy) ground, and may be exceeded 
approximately 10% of the time. Quoted maximum decel- 
eration rates are chosen to limit loads on the vehicles and 
occupants, and are less than the maximum possible decel- 
erations used in an emergency stop situation permitted by 


the friction between the wheel and the ground. The 2 sec 
reaction times are estimates for a human operator. An ad- 
ditional 3 sec round trip time delay is added to the LER 
Moon. 

Lunar terrain hazards [7] addressed are slopes and 
discrete obstacles, such as ejecta blocks associated with 
crater rims (Figure 9). The maximum obstacle height that 
a wheel can surmount is typically given by 0.7 times the 
wheel radius. We assume more conservative values (Ta- 
ble 1) given to us to limit shock impact to the vehicle sus- 
pension. From these we deduce a maximum traversable 
negative obstacle (hole) size. 

Additional requirements are to operate in dark or 
shadowed regions, limit the onboard computational re- 
sources to a single laptop (a 2. 3 3 GHz dual pentium with 
2GB memory), and use common sensors, avionics and 
software to the greatest extent possible across all rovers. 

3 System Overview 

Our approach to high speed navigation uses multiple 
scanning laser rangefinders (lidars) in a push-broom con- 
figuration to sense the terrain geometry as the rover ad- 
vances. Terrain points (specified in a site centered coordi- 
nate frame) are deduced from range measurements com- 
bined with vehicle pose (interpolated from pose estimates 
before and after each scan), and used to generate local 
traversability maps centered around the rover. Maps, 3D 
points, and rovers state are sent to an (off-board or on- 
board) immersive 3D GUI for tele-operation and situa- 
tional awareness. Maps and rover state are also sent to 
the onboard navigator software to autonomously drive the 
rover (if desired). The navigator is based on the classic 
Ranger/Morphin architecture first described in [9], and in 
use by many vehicles today including MER, incorporating 
a local path planner combined with a global planner (such 
as D* [10]) operating on a larger but lower resolution map 
build up from successive local map updates. 

4 Relevant Work 

The Stanford Darpa Grand Challenge vehicle Stanley 
[12] established an efficient statistically grounded method 
for detecting obstacles with single line scanning lidars 
based on the height differences within a neighborhood 
[12]. This proved effective for obstacle detection on rel- 
atively flat terrain (roads), but to traverse extreme terrain 
it is desirable to check potential paths against a full 3D 
terrain reconstruction such as [17] which uses a reduced 
triangulated mesh terrain representation to navigate a ve- 
hicle at slow speeds (1 cm/s) with regular stops. 

As vehicle speeds increase, non-holonomic motion 
constraints become pronounced with the result global path 
planners such as D* produce unfeasible trajectories. [8] 



Figure 4. : Ballet Crater (Apollo 17) 


seeks to improve the performance of the Ranger archi- 
tecture using more realistic motion primitives, while [4] 
demonstrates combined local and global planning in a 
higher dimension lattice that guarantees feasible paths at 
the expense of more computation than available to us. 


5 Sensors 


Terrain and hazard detection sensors consist of scan- 
ning laser rangefinders (the SICK LMS291 and Hokuyo 
UTM-30LX ) in a forward looking push-broom configu- 
ration, arranged with various look ahead distances. For- 
ward looking stereo cameras (PGRFlea’s, synchronized 
over the firewire bus) provide stereo ranging with a 100 ° 
field of view to complement the lidars. Pose sensing is 
accomplished with an Xsens MTi-G INS, a Honeywell 
HMR3000 compass/inclinometer, Novatel carrier phase 
DGPS and vehicle odometry (except on the LER, where 
we rely on the vehicle’s own pose estimation system pro- 
vided by it’s makers). 

The look ahead distance to detect discrete obstacles is 
given by the maneuvering distance, which we choose as 
the maximum of stopping distance and swerving distance 
[15], plus a safety margin accounting for map cell sizes 
and distance from sensors to the vehicle front. 
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coefficient of friction times the acceleration due to grav- 
ity). 

The look ahead distance for slope detection is given 
by the obstacle maneuvering distance above plus half the 
vehicle wheel base. 

The maximum traversable obstacle height imposes 
the requirement that the range sensors be able to resolve 
height differences half that at the obstacle detection look 
ahead. The required horizontal along-track resolution is 
similarly determined by the maximum traversable hole 
size. We assume that obstacles are at least as wide as tall, 
and therefore require a cross track resolution equal to the 
vertical resolution. Table 1 shows derived detection dis- 
tances and resolutions. 

A forward looking scanning laser rangefinder (lidar) 
vertical resolution is given by 


dvert — V Sin(0) + 


r6 

fscan COS (6) 


(3) 


where theta is the angle between the horizontal plane and 
the lidar beam (in radians), r is the slant range, and f scan 
the scanning frequency (in Hz). The horizontal along- 
track resolution is given by 


3 along track 
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Table 3 summarizes the lidar performance for each rover 
at the obstacle detection distance (the slope detection re- 
quirements are less restrictive). For further details on lidar 
and stereo requirements see [15] 


6 Terrain Mapping and Hazard Detection 


where v is rover speed, T react is the reaction time, so the 
swerving distance, and a the maximum permitted accel- 
eration or deceleration (limited by jag, the wheel/ground 


The terrain hazards we consider are slopes, discrete 
obsacles (e.g. ejecta blocks) and voids. Slopes hazards 
are mapped using the Time-Windowed variant of Morphin 




Table 2. : Rover maneuvering distances and resultant lidar 
requirements. 



K10 

LATU\ 

r LER 

LER 

Moon 

Stopping distance 
(m) 

1.3 

5.0 

8.3 

12.0 

Swerving dis- 

tance (m) 

1.2 

6.0 

9.9 

13.6 

Margin (m) 

3.0 

3.0 

4.9 

6.8 

Positive obstacle 
lookahead (m) 

4.3 

9.0 

14.8 

20.4 

Slope look ahead 
(m) 

4.8 

9.9 

17.0 

22.6 

Required vertical 
resolution (cm) 

5 

4.5 

7.5 

7.5 

Required cross- 
track resolution 
(cm) 

5 

4.5 

7.5 

7.5 

Required along- 
track resolution 
(cm) 

15 

23 

25 

25 


Table 3. : Rover lidar performance figures at obstacle de- 
tection distance from sensors. 



K10 

LATU\ 

r LER 

LER 

Moon 

Lidar 

UTM 

LMS 

291 

LMS 

291 

(tbd) 

Inter-point angle 

(°) 

0.25 

0.25 

0.25 

0.25 

Scan rate (Hz) 

40 

75 

75 

75 

Vertical resolu- 
tion (cm) 

2 

2 

4 

5 

Cross-track reso- 
lution directly in 
front (cm) 

1 

3 

6 

8 

Along-track reso- 
lution (cm) 

3 

12 

18 

28 


[7] (Figure 6) and obstacles with a variant of the Proba- 
bilistic Terrain Analysis[ 13] (Figure 7). Void detection is 
currently still under investigation but not yet part of our 
system. 

Time Windowed Morphin (TWM) is based on the ob- 
servation that relative pose errors increase over time so 
that terrain points measured close in time are more likely 
to be consistent. TWM by fitting planes to the most re- 
cent points within a time window at each map grid cell, 
followed by the standard Morphin travers ability analysis 
[9] of the plane slopes and residuals over a rover sized 
patch. 

Rover pose noise induces terrain reconstruction errors 
often exceeding discrete obstacle sizes. Because of this, 
and an 0(n 4 ) (for an n x n map), TWM is ill suited for 
detecting small obstacles, especially as greater map reso- 
lution is needed to localize these. 

Probabilistic Terrain Analysis (PTA) marks a cell as 
untraversable if two measured terrain points within a dis- 
tance 6 of each other differ in height by more than S plus 
a margin that increases with the time difference between 
when the points were measured, taking into account sen- 
sor geometries and pose estimation error characteristics 
in a principled manner. Only points measured within a 
specific time interval of each other are used in our vari- 
ant of PTA (since, unlike in the Darpa Grand Challenge 
for which PTA was developed, our rovers have multiple 
opportunities to probe the same terrain). PTA is computa- 
tionally very efficient (0(n 2 ) for an n x n map) and robust 
to most pose estimate noise (in fact, noise robustness can 
be traded against obstacle size detection limits.) 

The TWM and PTA maps are pessimistically com- 
bined (that is, we take the worst case traversability assess- 
ment above a given confidence threshold), and the resul- 
tant map sent to the navigator module and/or the user in- 
terface. 

7 Pose Estimation 

High rate (25Hz) locally accurate pose information, 
particularly attitude, is required to transform lidar points 
into a common reference frame for mapping. For K10 
(and eventually LATUV) we rely on the Xsens MTi-G 
INS, which uses MEMS accelerometers, gyros and a mag- 
netometer inputs to produce roll/pitch estimates with 0.5 °, 
and yaw estimates with 2.0 ° quoted static accuracies. In 
practice, a slowly varying attitude offset up to ± 5.0° 
is sometimes observed, and accuracy is significantly de- 
graded by vibrations due to the rover traversing rough ter- 
rain or maneuvering. 

Position estimates are obtained from odometry, cor- 
rected by differential GPS updates in a standard EKF. The 
EKF improves the INS attitude estimates by estimating 
the INS attitude error (in roll, pitch and yaw), modeled as 






Figure 6. : Time Windowed Morphin traversability map. 
Green areas have slopes <13°, red areas have slopes > 
23°. 


a first order damped Gauss-Markov process: 

6q(t + At) = mq(t ) + cr Vl - (D 2 ?? (5) 

where <I> = e~ A,/r , cr and r are process noise standard de- 
viation and time constant respectively, and q is zero mean, 
unit variance white Gaussian noise. The estimated attitude 
is then given as 

q = q' + Sq (6) 

where q' is the INS roll/pitch/yaw output, and Sq is the 
EKF estimate of the INS error. This indirect filter ap- 
proach combines the rapid response time of the INS to 
attitude changes with the improved static accuracy avail- 
able from the HMR3000 compass/inclinometer. 

In environments where the magnetic field is unreli- 
able for yaw estimates (such as high magnetic latitudes) 
the INS is operated in a mode that ignores the internal 
magnetometer, providing yaw estimates by integrating the 
gyros only. In this case, we use a random walk process 
model for the yaw error estimate: 

Sq(t + At) = Sq{t) + a Va ~tq (7) 

where a is the angular random walk ( ° / yfs), and external 
yaw corrections are provided by a suntracker [1]. 

On the LER we rely on a separate pose estimation 
system provided by its makers, using a Hemisphere Vec- 
tor GPS, Microstrain 3DMGX1 inclinometer, Crossbow 
VG700 fiber optic vertical gyro and vehicle odometry. 
The VG700 quotes 2.0 ° roll and pitch accuracies, but the 
overall system accuracy is unknown. 



Figure 7. : Probabilistic Terrain Analysis (PTA).The red 
areas have confirmed obstacles at least 10cm high. Areas 
with sufficient measurements but no obstacles are labelled 
traversable (green). 


8 Software Infrastructure 

Increased navigation speed poses challenges to the 
software infrastructure. The data volume of the naviga- 
tion sensors is significant and needs to be delivered to the 
relevant processing modules. Push models ensure lower 
latencies but carry the risk of clogging, if parts of the pro- 
cessing pipeline don’t keep up with the load. But soft real- 
time requirements now apply to entire software system, so 
the individual modules need to become insulated from la- 
tency spikes in other sub-system components. 

Controlling a dynamic vehicle in this distributed en- 
vironment also poses unique challenges in terms of engi- 
neering support. For adequately assessing analyzing sys- 
tem performance, it is crucial to enable the analysis and 
replay of data traces of the entire distributed system. 

We addressed these challenges in the design of IRG’s 
Service Oriented Robotics Architecture (SORA)[2]. For 
managing the high data volume in this challenging 
distributed environment, we deploy proven middleware 
technologies, namely CORBA (for commanding) and 
DDS (for data distribution). The middleware- supported 
publish- subscribe infrastructure provides a push-model 
for sensor data delivery while providing extensive qual- 
ity of service management, that facilitates a central ca- 
pability for load management. Modelling the individual 
subsystems as insulated services with high-level interfaces 
provides an adequate insulation of the modules. Fatency 
peaks can be more easily located and addressed within 
the individual subsystem. The software infrastructure also 
provides generic logging capabilities provided by Miro 
(Middleware for Robots) [16]. It allows distributed real- 


time logging of data streams as well as the synchronized 
replay of such acquired log-files. 

A recurring challenge in software-intensive systems 
is the integration of outside software components. In this 
particular case, a target platform, LER, is developed at 
another NASA center. Sensor data provided by the LER 
vehicle is crucial input for the navigation system. For this 
purpose we are using the Robot API Delegate (RAPID), 
an intercenter robot API, which is also based on DDS mid- 
dleware. This significantly reduced the integration effort 
and enabled the integration of LER provided telemetry 
into the hazard-analysis. 

9 User Interfaces 

The best tele-operation user interface [5] displays a 
3D visualization of the rover situated within a terrain re- 
construction, colorized either by surface albedo (and ap- 
propriately shaded to indicate slope) or in false colors ac- 
cording to traversability. VERVE (Visual Environment 
for Remote and Virtual Exploration) is our high perfor- 
mance 3D user interface used for real time visualization 
of robots’ activities. VERVE is geared toward visualiz- 
ing highly dynamic environments and monitoring multiple 
robots simultaneously. VERVE (Figure 8) allows opera- 
tors to visualize robot pose and configuration, raw sensor 
data, and derived data such as navigation maps and path 
plans (at present we are unable to obtain terrain albedo 
from our sensors). 

VERVE is component based software which is com- 
prised of many Java plugins, or bundles, that are as- 
sembled into an end user application. Specifically, it is 
built on top of the Eclipse RCP (Rich Client Platform) 
which is an implementation of the OSGi Framework[18]. 
The OSGi programming model encourages modularity 



Figure 8. : VERVE user interface, showing the K10 rover 
on a 3D terrain reconstruction (from lidar measurements) 
with traversability analysis overlaid. 


and code reuse and permits new capabilities to be eas- 
ily inserted into existing applications. The flexibility 
of the component based development approach allows 
VERVE to be easily retargeted to different end user 
applications [ 14] [ 1 1 ] . 

In order to monitor the activities of multiple robots 
which may have different communication mechanisms, 
VERVE decouples telemetry data transport from the 
graphical display. The most commonly used telemetry 
components in VERVE are the COBRA Notification Ser- 
vice and OMG Data Distribution Service (DDS), but new 
networking middleware can be easily supported by adding 
additional event collector components. Each event col- 
lector is responsible for gathering telemetry and distribut- 
ing it internally to data listeners. Data delivery is asyn- 
chronous and event throttling is handled within the event 
collector. 

In order to represent the robots in the 3D virtual 
world, each avatar is modelled as a collection of loosely 
coupled parts. Each part binds data received though event 
collection to an action on the scene graph. In the sim- 
ple case of joint angle telemetry, a data event would up- 
date transform nodes in the graphical 3D model, whereas 
a navigation map data event would trigger reconstruction 
of the height field mesh. The 3D scene is updated at 
a fixed rate (typically 30Hz), and telemetry is processed 
asynchronously upon arrival. 

Parts may be freely mixed and matched and are often 
reused between robots. Because data transport is decou- 
pled from the rest of the system in the telemetry compo- 
nents, a single, logical robot avatar can consist of subsys- 
tems which use different communication protocols. 

10 Performance 

Table 4 summarizes worst case algorithm perfor- 
mance rates on a representative test problem. K10, 
LATUV and LER lidars produce 58, 223 and 223 thou- 
sand points/sec respectively, well within the processing 
capacity of the laptop navigation computer. The limiting 
factor is the rate at which the Time Windowed Morphin 
map can be updated. 

11 Conclusions and Further Work 

We have described a flexible navigation system de- 
signed to fit the needs of several distinct lunar rover pro- 
totypes, spanning a range of sizes, speeds and opera- 
tional modes, using a common set of sensors and software. 
The system is currently autonomously navigating the K10 
rover, and tested as a pilot aid for the LER on Earth. The 
sensor analysis suggests that sensors with similar perfor- 
mance could be used to remotely operate the LER on the 


Table 4. : Execution speed 



Dell Pre- 
cision 

MacBook 

Pro 

Clock speed 

2.33GHz 

2.8GHz 

No. processors 

2 

2 

Memory 

2GB 

4GB 

OS 

RH5 

MacOs 


(linux) 

10.5 

Coordinate transforms (mil- 
lion points/sec) 

15.4 

5.77 

Adding points to PTA map 
(million points/sec) 

5.57 

5.77 

Adding points to TwMor- 
phin map (million 

points/sec) 

2.34 

2.36 

PTA Map Update rate 

59Hz 

79Hz 

TwMorphin Map Update 
rate 

0.44Hz 

0.55Hz 


Moon with a 3 sec round trip signal delay plus 2 sec oper- 
ator reaction time. 

The major weakness of the current system is a suscep- 
tibility to un-modeled pose estimate noise and the limited 
opportunities to sense the terrain as the rover drives for- 
ward. For example, when cresting a hill in the LER (Fig- 
ure 1) the forward looking lidars were unable to see the 
ground, or did not see far ahead when driving down the 
hill. Both problems are reduced, if not eliminated, with 
more terrain sensors, covering both a greater vertical field 
of view and in a smaller time interval. While full frame 
range sensing (such as with stereo imaging or flash lidar) 
is ideal, an analysis of the geometry shows it to be un- 
necessary. Multiple closely space scanning lidars, if in a 
suitably dense configuration (such as a Velodyne sensor) 
are sufficient. 

The use of GPS continues to be an irritant in our sys- 
tem. Besides being unavailable on the Moon, GPS esti- 
mates contain discontinuities and drift that negatively af- 
fect map construction. The ideal pose estimate system 
would be locally accurate, compensate for slip and dis- 
continuity free. 

The grazing lidar-ground angles required for any 
reasonable look ahead distance result in the occlusion 
of many areas, including potential negative obstacles 
(PNO’s or voids). It behooves us to explicitly detect oc- 
cluded regions and distinguish them from unexplored ar- 
eas. We have obtained promising results using a linear 
filter to predict the location of terrain measurements in the 
absence of occlusion based on previous measurements. 
Areas with predicted measurements but few real measure- 
ments are labelled as occluded (Figure 9); 



Figure 9. : Occlusion map of a crater generated as the K10 
rover drives towards it on the indicated path (occluded ar- 
eas are red). 


Computational constraints drove our decision to use 
grid based 2D C-space traversability maps for navigation, 
justified by our performance numbers (Table 4). It is un- 
clear how well this approach will handle autonomous nav- 
igation on extremely rugged terrain wherein hazards in- 
clude high centering, direction dependent tip-overs, and 
dynamic effects (such as becoming airborne after hitting a 
bump in low gravity). Promising approaches include gen- 
erating reduced 3D triangulated meshes [17] to represent 
terrain, and dynamical simulations and lattice space path 
planning [4] for more complex maneuvers. Unfortunately, 
the terrain mesh approach does not take pose error in- 
duced reconstruction noise into account and would there- 
fore miss small obstacles using the current sensor suite (it 
requires full frame 3D scans) and at present requires too 
much computation. 

It is desirable to modulate vehicle speed in response 
to terrain properties, for example when approaching an 
occluded area (eg cresting a hill) that may contain an ob- 
stacle. In this situation an appropriate response is to slow 
down until the occluded area is in full view (and confirmed 
safe) but not necessarily detour around it. To date, veloc- 
ity planning is done at the goal level. We are investigating 
local, variable velocity, trajectory planning (Figure 10). 
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